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ABSTRACT 


A new  ICES  executive  was  developed  for  the  IBM/370  to  provide  more  flexi- 
bility for  engineering  use  via  on-line  and  background  computing  environments 
and  also  to  provide  ease  of  maintainability  and  improve  further  development. 
Input  can  be  prepared  and  checked  (syntactically  and  graphically)  in  an  on-line 
mode,  small  analyses  run  and  checked  on-line,  large  analyses  run  in  batch  mode, 
and  results  checked  graphically  on-line. 

Two  new  versions  of  ICES  exist:  an  on-line  (CMS)  version  and  a batch 

(VS)  version.  The  source,  except  for  a few  programs,  is  independent  of  the 
version.  This  report  describes  the  changes  made,  the  reasons  for  the  changes, 
new  commands  developed  for  on-line  use,  and  performance  comparisons  with  the 
previous  M.I.T.  version  of  ICES. 
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I.  INTUODUCnON  AND  BACKGROUND 
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ICES  was  originally  developed  by  the  M.l.'l.  Civil  Engineering  Systems 
Laboratory  and  made  available  to  the  public  in  19b7.^^^  That  original  version 
was  developed  for  an  IBM  System  3b0  computer  and  ran  on  both  stand-alone  batch 
(PCP)  and  multi-tasking  batch  (MVT)  of  OS/360.  ICES  and  S'lRUDL  were  implemen- 
ted at  M.I.T.  Lincoln  Laboratory  in  the  late  19fa()s  as  batch  systems  on  the 
S/360. 

When  the  Model  67  of  the  S/360  was  installed  at  the  M.I.T.  campus,  an  in- 

[21 

teractive  version  of  ICES  was  developed  to  run  under  CP-67/CMS. ^ ' This  ver- 
sion included  many  of  the  changes  made  later  at  Lincoln  Laboratory  for  S/370 
CMS-ICES  and  which  are  the  subject  of  this  report.  The  M.I.T.  CP-67/CMS  ver- 
sion was  developed  as  an  experimental  version  and  hence  was  not  made  available 
to  the  public.  However,  an  object  version  of  CP-67/CMS  ICES  was  obtained 
b>-  Lincoln  Laboratory  and  used  for  small  STRUDL  runs  and  program  development 
until  the  IBM  360  computer  was  replaced  with  the  IBM  370  computer.  Duf  to 
differences  in  CMS  under  the  two  systems,  the  360  CMS  version  of  trps  ujuld 
not  operate  under  370  CMS.  Unfortunately,  by  this  time  the  interactive  vei- 
sion  at  the  M.I.T.  campus  was  no  longer  being  used,  and  all  source  for  the 
CP-67/CMS  version  of  ICES  had  been  lost. 

This  non-availability  of  source  presented  several  problems;  availability 
of  source  when  going  out  fo'^  bids  on  a new  computer,  and  availability  of  source 
for  maintaining  and  developing  those  sj'stems  used  for  contract  jobs. 

It  was  desired  to  have  STRUDL  aifailable  for  general  use  in  both  interac- 
tive and  batch  environments,  with  commonality  of  input  files.  VM/370  provides 
this  capability  since  CMS  files  are  able  to  be  used  as  input  streams  to  VS/370. 
Erom  an  engineering  user  standpoint,  the  availability  of  STRUDL  in  both  envi- 
ronments is  highly  desirable.  Tlic  CMS  (interactive)  environment  can  be  list'd 
foi  command  syntax  checking  and  for  relatively  small  anal)'scs  (on  the  order 
of  up  to  3 CPU  minutes),  while  the  batch  (VS)  environment  can  be  used  for 
larger  runs  (greater  than  3 CPU  minutes).  The  (iMS  environment  is  also  useful 
for  the  maintenance  and  develoiiment  of  subsystems  such  as  STRUIH,. 
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lor  these  reasons,  the  decision  was  made  to  develop  a CMS/370  version  of 
IChS,  workinj^  from  the  current  V1M3  source  distributed  by  the  ICES  Users  Group 
and  the  unpublished  write-up  of  the  changes  made  to  implement  CP-67/CMS 
ICES.  Compat  itii  1 ity  between  the  source  files,  the  source  listings,  and  the 
object  (compiled  source)  files  was  required. 

The  S'l'RUDl.  subsystem  had  lieen  implemented  at  Lincoln  Laboratory  under  360/ 
CMS  and  subroutine  listings  and  source  object  files  were  available  from  that 
conversion.  In  that  effort  the  source  subroutines  had  been  compiled  under 
G-Level  fortran  and  had  removed  source  program  incompatibilities  between  E- 
I.evel  and  G-Level  fortran,  most  notably: 

a.  The  rules  for  branching  into  DO  Loops  must  be  adhered  to  in 
fortran  G,  whereas  they  do  not  have  to  be  followed  in  fortran  E. 

I'here  were  a number  of  STRUDL  programs  in  wliich  illegal  branches 
into  DO  loops  were  made. 

b . A variable  can  be  equivalenccd  to  an  clement  of  a dimensioned  array 
beyond  the  limit  of  its  dimensioned  length  in  fortran  f!;  in 
fortran  G,  tliis  results  in  an  error  during  compilation.  Several 
STRIIUL  programs  required  a change  to  eliminate  this. 

fiven  thougli  the  370/CMS  version  of  STRUDL  was  compiled  witli  fortran  G, 
the  ICETRAN  precompiler  was  not  changed  to  ]icrmit  G-Level  fortran  statements. 
(.!-Level  statements  ma\'  be  added  after  COMMON  resolution  statements  by  placing 
a P in  card  column  1 which  causes  the  precompiler  to  bypass  that  statement. 
COMMON  resolution  statements  can  be  either  DYNAMIC  ARRAY  or  DOUBLE  PRECISION 
statements  as  well  as  COMMON  statements.  This  may  only  he  done  for  statements 
which  do  not  contain  dynamic  array  references. 

The  37D/CMS  STRUDL  implementat i on , then,  involved  the  generation  of  all 
the  modules  and  the  recreation  of  the  CDBs  in  the  ICES  system  data  set  DD3. 
Additional  work  was  done  on  370/CMS  STRUDI,,  however,  to  update,  expand,  and 
debug  the  finite  element,  dynamics,  and  substructuring  capab  i 1 i t i es . ^ ^ 


After  the  370/CMS-ICES  (hereafter  called  CMS-ICES)  implementation  was  com- 
pleted, a similar  version  was  developed  for  VS.  Here  the  objective  was  to  have 
a batch  version  which  was  exactly  the  same  as  the  interactive  version  at  the 
subsystem  level  and  which  had  minimal  variations  in  programs  at  the  ICES  execu- 
tive level.  This  latter  requirement  was  achieved  with  the  variations  occurring 
in  the  I/O  macros  and  the  module  generation  procedure. 

This  report  describes  the  changes  which  were  made  to  the  ICES  System  to 
develop  a time  sharing  version  for  370-CMS  and  a 370  VS  version.  In  this 
report,  the  following  nomenclature  is  used: 

1.  OS- ICES:  the  version  of  ICES  written  for  the  IBM  System  360  to 

operate  under  the  OS/360  or  OS/370  Operating  System. 

2.  CMS-ICES:  the  version  of  ICES  developed  at  Lincoln  Laboratory  to 

operate  under  VM/370  (Virtual  Machine  Facility  for  the 
IBM  S/370)  using  the  CMS  (Conversational  Monitor  System) 
subset  of  VM/370. 

3.  VS-ICES:  the  version  of  ICES  developed  at  Lincoln  Laboratory  to 

operate  under  the  VS  (Virtual  Memory  System)  operating 
system  for  the  IBM  S/370.  Versions  for  both  VSl  and  VS2 
were  developed,  and  VS-ICES  refers  to  either  of  them. 
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II.  ICES  DEVELOPMENT 


A.  OS  TO  CMS  CONVERSION 

The  differences  between  OS  and  CMS- ICES  are  described  in  the  follow- 
ing sections. 

1 . Program  Management  and  Dynamic  Loading 

The  OS- ICES  approach  to  dynamic  loading  is  retained,  i.e., 
single  entry  load  modules  are  used  with  extra  entry  points  being  ob- 
tained with  the  use  of  aliases  and  a start-up  routine  at  the  begin- 
ning of  each  module  to  search  a table  for  the  correct  entry  point 
for  the  alias.  However,  the  CMS  modules  may  have  unresolved  external 
references  resolvable  at  load  time,  system  COMMON  being  one  of  these. 

A directory  of  module  and  alias  names  is  necessar>'  so  that  the 
ICES  program  management  routines  may  know  the  actual  module  to  load 
for  any  requested  entry  point.  This  directory  information  is  placed 
in  a file  of  type  BLDL  that  is  read  by  a root  program  BLDL.  This 
replaces  the  OS  BLDL  macro  which  returns  the  same  information.  Since 
CMS  dynamic  loading  can  be  from  a TXTLIB  (a  collection  of  TEXT  files 
with  a directory),  a notation  can  be  made  in  the  BLDL  file  indicating 
the  TXTLIB  or  TXTLIBs  to  be  searched  by  CMS  to  find  the  required 
module.  If  the  BLDL  files  indicate  that  one  or  more  TXTLIBs  are  to 
be  searched,  the  BLDL  routine  issues  a GLOBAL  TXTLIB  command  for 
those  mentioned. 

Since  the  BLDL  information  must  reside  in  memory  and  since  this 
information  for  all  subsystems  would  take  up  an  unwarranted  amount 
of  space,  the  BLDL  routine  is  arranged  to  read  a system  directory 
(ICE.S  BLDL)  and  a subsystem  directory  ( iubiijitctmame  BLDL).  When  a 
new  subsystem  is  initiated,  the  BLDL  routine  overlays  the  old  stibsys- 
tem  BLDL  with  the  new,  the  subsystem  name  being  obtained  from  tlie 
first  8 bytes  of  system  COMMON. 
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The  LINKEDIT  routine  is  used  to  create  the  single  entry  load 
modules  required.  They  are  in  fact  normal  CMS  TEXT  files  that  can 
be  used  by  the  CMS  dynamic  loading  routines.  The  LINKEDIT  routine 
is  described  in  the  section  on  load  module  generation. 

Since  the  implementation  of  the  CMS  LOAD  macro  would  not  reuse 
memory  space  correctly,  the  LOAD  was  replaced  by  a combination 
GETMAIN  and  INCLUDE;  the  DELETE  was  thus  replaced  by  a FREEMAIN. 

Overlay  structuring  of  load  modules  in  CMS- ICES  is  not  supported 
because  of  the  complexity  of  the  problem.  The  root  is  thus  not  over- 
lain,  leading  to  greater  efficiency  in  the  root  routines  but  cutting 
down  the  user  area  available  to  subsystem  programs  and  data. 

2.  COMMON  References 

The  whole  method  of  handling  a systemwide  COMMON  is  changed  for 
CMS- ICES.  In  OS,  COMMON  can  only  be  placed  within  load  modules,  there 
being  no  provision  for  the  systemwide  COMMON  required  by  ICES.  Thus, 
part  of  the  starting  up  routine  in  all  OS-ICES  modules  searches  all 
the  routines  in  the  modules  that  contain  COMMON  references  and  re- 
places the  references  in  their  prologues  with  the  actual  address  pro- 
vided by  the  ICES  root. 

In  CMS-ICES  the  load  modules  may  have  references  resolved  to  a 
systemwide  COMMON  at  load  time,  the  only  requirement  being  that  the 
ICES  root  must  place  the  correct  COMMON  address  in  the  CMS  loader 
reference  table.  This  latter  step  is  necessary  because  a combined 
system  and  subsystem  COMMON  is  reobtained  every  time  a new  subsystem 
is  initialized.  The  root  routines  always  obtain  the  COMMON  address 
from  the  entry  point  QQCOMADR  which  is  updated  by  INAL,  the  COMMON 
obtaining  routine. 

One  problem,  however,  is  that  ICES  unfortunately  makes  frequent 
use  of  the  fact  that  E- Level  FORTRAN  keeps  the  COMMON  address  in 
register  4,  while  G-Level  usually  keeps  the  address  of  the  previous 
save  area  in  this  register.  Nearly  all  the  interface  routines 
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included  in  modules  from  the  IfliS  function  library  assume  the  COMMON 
address  is  in  register  4 and  many  of  the  routines  they  call  in  the 
root  also  assume  this.  Tlierefore,  most  of  the  function  1 ibrar.v  rou- 
tines have  had  to  be  altered  to  obtain  the  COMMON  address  from  an 
entrv'  point  QQCOMADR  included  in  the  load  module  starting  routine 
STARTMOD.  It  is  also  necessary  to  make  a number  of  routines  return 
to  the  interface  routines  to  have  register  4 reset  before  returning 
to  the  C-Level  routines  in  the  module.  I'his  reduces  the  efficienc)’ 
of  the  dynamic  data  routines  in  the  root  as  each  return  is  delayed. 

In  addition,  debugging  is  complicated  because  the  return  indicated 
when  a dynamic  array  error  is  obtained  is  in  an  interface  routine  in- 
stead of  the  real  calling  routine.  The  real  return  will  be  printed 
in  one  of  the  two  words  which  follow  the  current  error  message  re- 
turn word. 

CMS-ICES  uses  bytes  29b  to  319  of  system  common  for  passing  I/O 
indicators  to  the  ICESIO  routine. 

3j Primary  Memory  Data  Management 

Since  CMS  lias  its  own  separate  area  for  its  work  space,  it  is 
only  necessary  to  ensure  that  ICES  leaves  enough  sjiace  in  high  ad- 
dress memory  for  an>'  possible  use  b>-  CMS.  ERtiEEOWE  is  the  CMS  nu- 
cleus indicator  that  indicates  the  lowest  high  core  location  used  b\' 
CMS.  If  CMS  requires  more  space,  it  may  lower  EREEl.OWE.  iTie  start  irq; 
up  routine  for  CMS-ICES  (STRTI CES)  ensures  that  CMS  has  at  levies t two 
free  pages  for  its  work . 

The  only  other  intruder  into  the  user  area  is  1 OR  TRAN  whicli  re- 
iiuires  buffer  space  for  datasets.  CMS-ICES  jirovides  an  interface 
for  datasets  5 and  b to  allow  interactive  manipulation  of  i nput  Ouit put 
and  buffer  space  for  these  is  provided  within  the  root.  However,  if 
a subsystem  user  uses  other  datasets,  iORTRAN  will  obtain  t h i '■  space 
with  CETMAINs  from  the  user  area.  There  is  no  reasonable  wa\  to  con- 
trol this  and  fragmentation  of  storage  m;iy  result. 
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4.  Secondary  Storage  Data  Management 

All  OS  disk  management  macros  arc  replaced  with  tlic  equivalent 
OMS  macros.  There  are  two  important  differences  between  these  OS 
and  CMS  routines.  In  OS  the  record  number  is  the  relative  record 
number  and  thus  the  first  record  is  referred  to  as  0.  In  CMS  this 
is  record  1.  In  OS  all  records  in  a file  must  be  initialized,  and 
when  all  have  been  used,  the  initialization  must  be  extended.  In 
CMS  all  records  on  the  user's  disk  are  initialized  and  records  are 
only  allotted  to  a file  when  the  record  is  actually  going  to  he  writ- 
ten. Thus,  the  concept  of  initialization  is  superfluous.  This  sec- 
tion of  coding  is  thus  removed  and  as  far  as  (iMS-UTiS  is  concerned, 
12448  records  have  been  initialized  for  a file,  this  ticing  the  maxi- 
mum that  can  be  handled  in  the  ICES  track  directory. 

The  four  ICES  datasets  are  named  DDl  ICES,  DD2  ICES,  01).^  ICES, 
and  DD4  ICES  for  CMS- ICES.  The  names  but  not  the  filetypes  may  be 
changed  by  using  the  ICES  renaming  facility  by  issuing  a call  to 
QQDSNC. 

CALL  QQDSNC  (do-ttzict  iiumbez,  new  name) 

5.  ICES  Ixiad  Modu le  Gonerat  i on 

Load  module  generation  is  controlled  liy  the  CMS  liXE.C  procedui'e 
MAKEMOD. 

Basically,  an  assembly  language  routine  STAKTMOD  is  created  for 
each  module  using  the  entrv  point  information  in  tlie  suhs\-stom  Blld. 
file.  The  entry  names  are  placed  in  a table  in  tlie  STARiMOD  routine, 
and  during  the  LINKE.DITing  procedure  the  addresses  of  the  entr\  points 
arc  also  placed  in  the  talile.  The  KiE.S  program  management  routines 
can  search  this  table  for  the  required  entry  point  address. 

Ihe  assembled  routine  .and  the  other  routines  reiju  i red  in  the 
module  arc  then  LINKldUi'ed  together  to  form  tlie  module,  .a  CMS  Tl  \'l 
file.  Tile  final  step  is  the  automatic  updating  ot'  the  BI.DI  file 
entry  for  the  module  with  the  module  size. 
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In  CMS-ICHS,  load  modules  arc  relocatable  CMS  TIIXT  files  pro- 
duced by  the  LlNKbDlT  procedure  during  load  module  generation. 

B.  CMS  TO  VS  CONVHRSION 

Conversion  to  VS  was  oriented  toward  keeping  as  many  programs  as  pos- 
sible the  same  as  in  CMS  and  improving  disk  operations  by  increasing  the 
size  of  the  disk  blocks.  On  CMS  the  disk  blocks  were  kept  at  800  since 
that  is  the  size  used  by  CMS  for  its  blocking.  I-or  VS,  a block  size  of 
4000  was  chosen. 

1.  ICHS  Load  Module  Generation 

The  module  generation  procedure  for  VS  was  designed  to  use  CMS 
text  decks  (i.e.,  compiles  would  be  done  on  (TIS)  and  non-overlay 
modules.  Texts  for  one  subsystem  are  stored  in  one  jiartitioned  data- 
set, and  the  VS  utility  lUBUPDTF,  is  used  to  add/rcplace  texts. 

Since  VS  does  not  have  anything  com}>arable  to  a loader  table, 
a different  method  for  handling  common  resolution  at  module  load  time 
had  to  be  found.  To  this  end,  a new  OSSFTC.FN  program  was  written 
which  would  find  all  adcons  to  COMMON  in  each  text  to  be  included  in 
a module  and  would  then  generate  code  for  program  Sl-.TUP,  which  pro- 
gram would  be  executed  when  tlie  module  was  given  control  after  load 
time.  The  code  generated  for  SPI'IIP  would  cause  each  adcon  to  he 
readjusted  from  linkage  editor  generated  load  module  COMMON  address 
to  the  global  (,'OMMON  address  for  that  sul'System. 

The  lengths  of  COMMON  in  each  text  (with  COMMON)  are  changetl  to 
4 by  jirogram  NIXCO  which  is  invoked  at  the  end  of  the  PRlTiOMI'  jiroee- 
dure  in  CMS. 

All  other  changes  in  the  VS  conversion  were  made  to  programs 
which  had  CMS  macros  in  them,  jirimarily  1/0  macros. 
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2 . Difference  Between  VSI  ICI'.S  and  VS2  ICt-S 

The  difference  in  the  primary  memory  management  methods  between 
VSI  and  VS2  has  caused  two  different  versions  of  0SFINCH2  to  be  de- 
veloped. VS2  allocates  primary  memory  in  the  manner  in  which  ICES 
assumed  for  its  QQQICEX2  scheme,  namely,  GETMAINs  from  high  address 
down  and  LOADs  from  low  address  up.  VSI,  however,  allocates  every- 
thing (except  links)  from  high  address  down,  and  in  so  doing  will 
increase  the  chances  for  memory  fragmentation  to  such  an  extent  that 
problems  run  on  VSI  will  take  about  50°o  more  CPU  time  and  100°o  more 
disk  I/O  operations  than  that  required  on  VS2.  This  degradation  was 
caused  by  fragmentation  which  in  turn  caused  increased  numbers  of 
of  reorgs  at  all  levels. 

Since  this  kind  of  degradation  was  intolerable,  a modified 
version  of  0SFINCH2  was  written  which,  by  the  use  of  GETMAINs  and 
FREEMAINs,  forces  a LOAD  to  be  made  in  the  lowest  address  available. 
With  this  change,  the  two  versions  of  ICES,  for  V'Sl  and  VS2 , have 
comparable  running  times. 

C.  TIME  COMPARISON  BETWEEN  0S~ ICES  AND  VS-ICES 

Two  STRIJDL  jobs  were  run  on  OS-ICES  and  VS-TCES  under  various  con- 
figurations to  compaT-e  performance  on  the  two  systems.  The  first  STRUDI. 
job  was  a dynamic  analysis  problem  with  1,16b  degrees  of  freedom  and  de- 
termines by  iteration  the  first  5 eigenvalues.  This  problem  had  21.^ 
joints,  136  members,  and  812  elements  of  which  384  were  CSTC.,  384  were 
CPT,  and  44  were  SECT.  The  maximum  half-bandwidth  started  at  128  .and  was 
reduced  to  30. 

The  second  SIRUDL  job  ..’.as  a stillness  anal\'sis  ot  the  .same  structure 
in  the  first  job  with  five  additional  members  and  five  additional  ioints. 
There  were  2.S  loading  conditions  imposed  upoti  the  structure.  The  maximum 
half-bandwidth  started  at  130  and  was  reduced  to  34. 


9 


The  d i f t'orences  in  the  ICliS  systems  were: 


1.  The  OS  system  was  the  non-overlay  root  with  modifications  to 
permit  a blocksize  of  6400  on  DD4  and  otherwise  equivalent  to 
V1M2  version  of  the  root,  i.e.,  it  did  not  have  facility  for 

50  pools  (only  20)  or  for  the  REORG  command.  The  ICES  root  used 
here  was  the  experimental  field  test  version  of  the  ECI  V1M2 
executive  before  release  of  their  proprietary  version.  The 
STRUDl.  system  for  OS  was  the  standard  Fortran  E version  of 
STRODE  and  had  a pool  size  of  350K. 

2.  The  VS  system  was  the  new  non-overlay  root  with  a blocksize  of 
4000  on  Dl)4  and  otherwise  equivalent  to  V1M4  version  of  the 
root,  i.e.,  up  to  50  pools  and  the  REORG  command  were  available. 
The  STRUDl.  system  for  VS  was  the  Fortran  G compiled  version  with 
no  overlay  modules  and  had  a pool  size  of  80K. 

Each  STRUDL  job  was  run  once  on  the  OS  version  in  regions  of  2048K 
and  4096K  and  was  run  several  times  on  the  VS  version  with  different 
values  for  the  REORG  parameter  and  different  region  sizes. 

The  items  measured  were  CPU  time,  number  of  direcv  access  I/O  opera- 
tions, number  of  paging  operations,  and  number  of  reorgs  for  each  level 
of  reorganization,  i'hese  statistics  are  given  in  Tables  II.C.I  and  11.G.2. 

It  can  be  seen  from  these  tables  that  tlie  VS  version  witli  RliORG  1 
gives  greatly  improved  performance  over  the  OS  version.  The  results  also 
illustrate  the  effect  of  region  size  on  system  performance.  It  should  he 
noted  that  all  runs  had  a cut-off  time  of  .50  GPU  minutes. 
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working  on  4th  eigenvalue  at  cancel  (due  to  30  min.  time) 


STATISTICS  lOR  RUN  01-  STRUDL  THSI 


D. 


NEW  USER  COMMANDS 


1.  The  IN  and  OUT  Commands 


There  are  two  CMS- ICES  System  commands  for  controlling  from 
where  input  is  to  come  (keyboard,  tape  or  disk  file)  and  where  out 
put  is  to  be  directed  (typewriter,  tape  or  disk  file,  printer,  or 
any  combination) . 


IN 


TYPE 

FILE 

DISK 


( 'filename ' ) ( ' fi letype' ) ( ' filemode' ) 
( ' filename ' ) ( ' fi letype ' ) ( ' filemode ' ) 
( ' tapenumber ' ) 


Input  can  come  from  the  keyboard  (TYPE),  or  from  a CMS  file 
(FILE  or  DISK),  or  from  a mag  tape  (MT) . If  a disk  file  is  to  be 
used,  and  {^dZcmodz,  or  and  and 

^■Ltejnodz  need  not  be  specified.  In  these  cases,  the  default  is  INPUT 
for  i-tlztyp^  and  ICES  for  ^d^enamc.  The  tapenmnbeA.  in  the  mag  tape 
option  specifies  the  CMS  tape  number.  The  default  is  1,  for  tape  181. 


OUT  TYPE 

NOTYPE 
PRINTER 

£I LE  ( ' fi lename ' ) ( ' fi letype ' ) ( ' f i lemodc ' ) 

DISK  ( 'filename ' ) ( ' f i letype ' ) ( ' f i lemode ' ) 

MT  ('tapenumber') 

Output  can  he  directed  to  any  or  all  of  the  three  devices: 
typewriter,  printer,  and  disk  file,  or  typewriter,  printer,  and  mag 
tape.  NOTYPE  must  be  specified  to  get  no  output.  If  a disk  file  is 
to  be  used,  ^idmodi’ , ^.<CeXlJp^  and  ^ddemode,  or  ((</cnnme  and  f^iCctypc 
and  ^d-tamodc  need  not  be  specified.  In  these  cases,  ttie  default  is 

1.^ 


OUTPUT  for  (5Tiet(/pe,  ICF.S  for  {liZenaim,  and  A for  jJTXemode.  If  a file 
of  ^T£enami!,  (either  specified  or  default)  already  exists, 

it  will  be  added  too.  The  default  TapenuinbeA  is  1,  again  for  tape  181. 

Note  that  these  commands  are  valid  also  in  VS;  however,  the  TYPE 
option  is  meaningless  in  the  batch  environment.  In  the  VS  version, 
the  standard  input  is  card  and  the  standard  output  is  PRINTER.  Also 
in  VS,  if  the  FILE  or  MT  option  is  specified,  then  there  must  be  an 
ICESINPT  UD  card  if  the  IN  command,  and  no  is  given,  and 

there  must  be  an  ICESOUT  DO  card  if  the  OUT  command  and  no 
is  given,  or  generally  a 1)1)  card  named  for  any  IN  or  OUT 

command . 

The  commands  IN  and  OUT  may  be  given  anytime  during  a run  and 
may  be  included  in  an  input  file  as  well  as  being  typed  in. 

2.  The  *RETURN  Command 


‘RETURN 


This  command  tells  the  system  to  resume  reading  commands  from 
the  same  input  fi le  which  was  being  used  when  a command  syntax  error 
was  detected  by  the  command  interpretor.  It  will  cause  processing 
to  continue  with  the  command  (line)  immediately  following  the  com- 
mand (line)  which  was  in  error.  Mien  a command  s>Titax  error  occurs 
while  reading  from  an  input  file,  the  system  types  out  a message  and 
returns  to  typewriter  input  mode.  At  this  point,  the  user  can  type 
in  the  correct  command  and  then  type  ‘RETURN  on  the  next  line  to 
cause  processing  to  resume  from  the  file.  Note  that  this  command  is 
meaningful  only  in  CMS  or  an  interactive  environment.  Also  note  that 
this  will  not  always  work  for  commands  in  repeat  loops. 
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3.  Other  System  Commands  [ 

MAP 

This  command  may  be  used  at  any  time  to  type  a current  map  of 
how  ICES  is  using  memory.  The  output  includes  the  name,  address, 
and  length  of  all  modules  currently  in  memory,  the  address  of  COMMON, 
and  the  address  and  length  of  all  data  pools. 

VERIFY  (OFF) 

This  command  controls  the  command  interpreter's  typing  back  of 
commands  and  messages.  If  the  option  OFF  is  specified,  this  verifi- 
cation (echo  typing)  is  suppressed.  Initiation  of  a subsystem 
automatically  turns  verification  on. 


E.  UTILITIES  IN  CAiS-ICES  FOR  SUBSYSTEM  DEVELOPMENT 

This  section  describes  EXEC  procedures  and  special  files  for  develop- 

I 

ment  of  ICES  subsystems  in  CMS. 

I.  Pre-Compilation  i 

An  EXEC  file  called  PRECOMP  will  cause  a specified  file  of  type 
ICETRAN  to  be  pre-compiled  by  the  ICETRAN  precompiler  and  the  re- 
sultant output  from  pre-compilation  to  be  compiled  by  the  G1 -Level  ' 

Fortran  compiler.  ■ 

PRECOMP  ((cTCHOmc 

where  ^'CtL’.name.  is  the  name  of  the  ICETRAN  source  program  to  be 
ICETRAN  precompiled  and  Fortran  compiled.  It  must  be  of  filetype 
ICETRAN  and  must  end  with  **F.OF'  starting  in  column  1. 
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The  output  of  this  procedure  will  be  a TEXT  file  named  ^'(J.enarne . 
If  more  than  one  subprogram  is  in  the  source  file,  only  one  **EOF 
line  should  be  in  the  source  file  (at  the  very  end).  Only  one  TEXT 
file  will  be  produced,  that  file  containing  the  objects  of  all  the 
subprograms  in  the  source  file. 

A listing  of  the  ICETRAN  source  file  and  the  Fortran  compilation 
is  produced  on  the  printer. 

2.  Load  Module  Generation  (CMS  Version) 

The  EXEC  procedure  MAKEMOD  will  cause  several  object  decks  (sev- 
eral text  files  from  pre-compilation)  to  be  linkage  edited  together, 
resolving  all  externs  among  themselves  and  routines  in  TXTLIBS  (such 
as  the  Fortran  library),  and  then  producing  an  executable  module  (CMS 
TEXT  file). 

MAKEMOD  iub-iy-!,te.mnatm  moduZcnatm 

where  2>ufa2>^2iTemname  is  the  name  of  the  ICES  subsystem 
and  modulanaim  is  the  name  of  the  module  to  be  created. 

This  procedure  assumes  that  two  other  files  already  exist,  narnel)’  the 
file  iub^y-itmnatm  BLDL  and  file  modulename  LIST  (or  file  iubsyitem- 
name.  BLDL  and  file  iubiyitzmnarm  LIST).  If  iub-iy-itemnamc  is  not  given 
this  procedure  assumes  that  only  one  other  file  already  exists,  namely 
the  file  tnoduZe.namd  LIST.  These  files  will  now  be  described. 

a.  The  BLDL  File 

The  subsystem  BLDL  file  has  two  uses  as  described  below: 

1)  CMS- ICES  requires  a file  with  a filet\pc  of  BLDL  for 
each  subsystem.  This  file  records  the  names  and  sizes 
of  the  modules  for  the  subsystem  and  the  aliases  (extra 
entry  prints)  for  each  module.  Its  filename  is  the 
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subsystem  name  stored  in  the  first  8 bytes  of  system 
COMMON.  The  actual  name  depends  on  how  the  subsystem 
was  initiated  and  it  is  suggested  that  the  user  store 
the  subsystem  name  he  requires  in  system  COMMON  during 
his  restart  procedure.  The  system  will  indicate  if  it 
cannot  find  the  required  subsystem  BLDL  file  by  typing 
the  name  for  which  it  was  searching.  System  COMMON 
may  be  preset  in  the  restart  j)rocedure  with  the  follow- 
ing CDl.  command; 

PRESET  ALPHA  8 'QQDUB'  EQ  ' subsystemname ' 

Note  ttiat  QQDUB  will  probably  have  to  be  added  to  the 
subsystem  common  map  at  location  0. 

During  execution  an  ICES  BLDL  and  a subsystem  BLDI.  are 
read  into  memory. 

This  file  also  acts  as  the  control  for  the  load  module 
generation  procedure  and  must  be  set  up  as  follows; 

Starting  in  column  1,  the  module  name  preceded  by 
QQ  or  the  alias  name  preceded  by  QQ. 

Starting  in  column  10,  six  zeros  if  a module 
name  or  the  module  name  preceded  by  QQ  if  an 
alias  name. 

Supjiose  a subsystem  consists  of  .S  modules  with 
aliases  for  two  of  those  modviles.  Its  BLDL  file 
would  be  established  as  follows: 
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QQSUBl  000000 

QQSUB2  QQSUBl 

QQSUBS  000000 

QQSUB4  000000 

QQSUB5  QQSUB4 

QQSUB6  QQSUBl 

where  the  left-hand  column  begins  in  column  1 
and  the  right-hand  column  begins  in  column  10. 

The  module  names  are  QQSUBl,  QQSUB3,  and  QQSUB4 , 
and  the  other  names  are  aliases  for  the  modules 
named  in  column  10. 

b.  The  LIST  File 

The  load  module  generation  procedure  requires  some  indica- 
tion of  what  routines  are  to  he  included  in  the  module  and  what 
TXTLIBs  to  search.  The  load  module  generation  procedure  requires 
that  this  information  be  given  in  a iubiij-i  tcmnume.  or  moduldname 
LIST  file. 

Suppose  a module  is  to  be  created  for  the  i'Oi’O  subsystem. 

Tlie  iubiy-itemnawe  I.IST  file  would  be  named  TOPO  1. 1ST  and  would  be 
established  as  follows: 

STARI'MOD 

* 

TOPO 
ICLLIB 
I'ORTLIB 
SYS LIB 

All  entries  begin  in  column  1.  STARTMOD  is  the  routine  created 
hy  the  load  module  generation  process  using  the  TOPO  BLUL  as  a 
control.  It  is  basically  a table  of  the  entr>’  names  for  tlic 
module.  The  * is  a fence  between  the  I'liXT  c’Hctmcs  and  the 
IXTLIB  e name  s . 
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The  LINKIiDIT  program  (whictt  is  invoked  by  the  MAKEMOD  pro- 
cedure) starts  by  including  the  STARTMOl)  TEXT  file  created  for 
the  module  (created  by  the  MAKEMOD  procedure).  If  we  were 
making  module  QQSUBl , mentioned  in  the  BLDL  example  above,  the 
LINKEDIT  program  would  then  search  for  the  .SUBl  and  SUB2  in 
TOPO  TXTEIB.  Any  programs  referenced  by  SlIBl  and  SUB2  would 
be  searched  for  also  in  TOPO.  When  no  more  external  refer- 
ences can  be  resolved  from  TOPO,  the  next  TXTEIB  mentioned, 
namely  ICELIB  (the  ICES  system  function  library),  would  be 
searched.  ITiis  continues  until  either  all  references  have  been 
resolved  or  until  the  end  of  the  LIST  file  is  reached. 

If  the  routines  to  be  used  in  the  module  do  not  exist  in  a 
TXTEIB  or  if  updated  versions  are  to  be  used  which  have  not  yet 
been  placed  in  the  TXTEIB,  a special  LIST  file  may  be  made  for 
the  module  indicating  exactly  what  routines  arc  to  be  used. 

Suppose  that  for  module  QQSUBl  routines  SUBl  and  SUb2  are 
not  to  be  obtained  from  TOPO  (i.e.,  they  are  to  be  obtained  from 
TEXT  files),  but  all  other  routines  are  to  be  obtained  from  a 
TXTEIB;  then  the  SUBl  LIST  file  would  be  created  as  follows; 

STARTMOU 

SUBl 

SUB.S 

* 

TOPO 
ICELIB 
PORTE IB 
SYSEIB 


HI 


Note  that  STARTMOD  must  always  be  the  first  entry  in  any  LIST 
file.  The  TXTLIBs  mentioned  are  always  searched  in  the  order 
entered  so  that  if  a routine  exists  in  more  than  one  TXTLIB  it 
will  be  obtained  from  the  first  TXTLIB  that  contained  it  pro- 
vided that  some  other  routine  mentioned  (referred  toj  it  before 
or  while  the  first  TXTLIB  was  being  searched. 

c.  MAKLMQL)  Examples 

In  tlie  example  above,  if  the  iubii/it^mname  LIST  file  is  to 
be  used,  the  procedure  for  module  generation  would  be: 

makl:moi)  topo  subi 

This  version  of  MAKLMOU  would  then  do  the  following: 

1)  Execute  SETGliNl  to  create  the  STARi’MOD  ASSEMBLE  file 
using  the  TOPO  BLDL  file  as  the  control. 

2)  Assemble  STARTMOD  ASSEMBLE  creating  STARTMOD  TEXT. 

,i)  Execute  LINKEDIT  to  create  the  module  QQSUBl  using  the 
SUBI  LIST  file  as  a control  if  one  exists  or,  if  not, 
the  TOPO  I.IST  file  as  a control. 

4)  lixecute  Bi.DLEDIT  to  store  the  module  size  in  the  TOPO 
BLD(.  file. 

5)  Erase  unwanted  files. 

If  the  modu£.L’yuii7K>.  LIST  file  is  to  be  used,  the  procedure  for 
module  generation  would  be: 

MAKE.MOl)  SUBI 

This  version  of  MAKEMOD  would  do  the  following: 

1]  Execute  SETCEN  to  create  the  .STARTMOD  ASSEMBLE  file 
using  the  SUBI  LIST  file  .as  the  control. 

2)  Assemble  STARi'MOl'  creating  STARiMOD  TLXi  . 
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3)  Execute  I.INKI'.DIT  to  create  the  module  using  the  SUBl 
LIST  file  as  a control. 

4)  Erase  unwanted  files. 

Note  that  in  tlie  second  example  above,  BEIU.EDIT  would  not  be  exe- 
cuted, and  thus  the  module  size  would  not  be  entered  into  the 
subsystem  BEDE  file.  This  would  then  have  to  be  done  separately 
as  described  in  the  next  section. 

d.  BED EE PIT 

BEDEEDIT  is  a program  which  inserts  the  module  length  in 
the  appropriate  position  in  the  subsystem  BEDE  file.  It  is  in- 
voked by: 

BEDEEDIT  iiubitjsti’mnairtc  Q^moduXenamc 

or  in  the  second  M\KEMOD  example  above,  the  MAKliMOD  would  be 
followed  by: 

BEDEEDIT  TOPO  QQSUBl 

3.  Eoad  Module  Generation  (VS  Version ) 

Module  generation  for  VS  consists  of  the  following: 

a.  Putting  any  changed  texts  into  the  partitioned  dataset  for 
the  subsystem  object  library.  'Ilie  \'S  utilit>'  program 
lEBlJPDTE  is  used  for  this. 

b.  Execute  PGM=QQtUBAK2  with  the  .apjirojir i ate  input  for  OSSlii'GEN 
to  make  the  modules.  The  object  librar.v  must  be  specified 
in  the  OB.I  DD  card. 


The  input  for  program  OSSlil'GliN  is  as  follows; 


column  1 column  10 

moiiofename 

( tt>  X f name,  1 [cufnyname  ) 

**P,0f 

where  fextnomc  is  the  name  in  the  object  library  of  the  program 
to  be  included  in  the  load  module;  and  cutVintXiTK'  is  one  of  the 
entry  points  (main  or  alias)  to  the  motlule  - the  mcr/at'ename  ent  r 
must  be  the  first  line  after  the  mt'd(t£ena/«e  line. 

The  parentheses  denote  optional. 

■ 1 , Cross  Refe renc e ^ ^ 

A listing  of  all  modules  in  a subsystem,  their  contents,  and  a 
list  of  all  modules  which  contain  each  program  can  be  ]iroduced  by  run 
ning  program  CROSS.  It  uses  the  set  of  input  for  program  OSSinCfN 
whicli  must  be  in  one  file.  Input  is  on  dataset  8;  output  is  on  data- 
set 10. 

5.^ CDl^  and  ICliS  ]j  ie  C_ei\erat  ion 

As  in  an>-  ICihS  system,  subs>stcm  commands  are  defined  to  the 
system  by  inputting  their  definitions,  using  CIM,  commands,  to  tiu' 

CDI,  subsystem.  This  is  done  as  a normal  ICIS  execution,  using  any 
of  the  system  commands  for  input/output  control,  e.g.,  ininit  Irom  a 
file,  out|Hit  to  a file,  etc.  The  CDI,  subsystem  creates  a Cldt  (com- 
mand definition  block)  for  each  command  definition.  These  Cl'bs  are 
written  onto  the  ICh.S  system  file,  est.ibl  i shed  in  t MS  ,is  Dl'a  ItlS. 


*> 


I 


i 

I 

I 


Besides  I'DiS  ICliS  as  tlie  system  file,  the  other  files  associated 
with  ICHS  processing  are; 

UDl  ICHS  the  user  data  file 

UDJ  ICl'.S  the  subsystem  data  file 

l)D4  ICliS  the  dynamic  memory  overflow  data  file. 

Dcbuggi ng  i n K.’hS 

Subsystem  debugging  can  he  simplified  by  using  the  llIiRlUi  form  of 
the  ICES  command. 

ICliS  lUiBlK'.  QQmoduf  ctiamc 

where  QQmeditf euamc  is  the  name  of  ti>e  module  in  wliich  one  wishes 
to  trace  the  flow  of  control  by  using  breakpoints  or  any  of  the 
other  t!MS  Dt'BlIC  facilities. 

When  module  QQmcdafCHamc  is  loaded  into  memory,  the  1(!I!S  system 
will  type  out  a m;i|)  of  memory  [similar  to  what  is  jiroduced  from  the 
MAP  command)  and  then  enter  the  CMS  liiiBlIC  environment.  Tlie  user  can 
then  issue  an\  valid  DEBUi;  commands,  such  as  breakpoints,  and  then  use 
the  OEBUG  facility  RETURN  command  to  return  to  the  UdiS  environment. 
After  returning  from  the  I'lBIlC  environment,  the  keyboard  will  unlock 
at  which  time  a QQnkidiU'i’namc  may  be  typed  by  the  user  to  spec  i f>-  the 
next  module  which  he  will  want  to  investigate.  If  he  does  not  want  to 
stop  again,  he  enters  a null  line.  The  next  QQmecfuf ciutmc  t>ped  in  m;i>- 
be  the  same  module  for  wliich  breakjio  i nt  s , etc.,  were  just  specified. 


HI.  SUBSYSTEM  niWl-  I.OPNinNT 

The  CMS- ICES  system  was  used  to  develop  additions  and  modifications  to  the 
S'l'RUl)!.  subsystem,  ihese  enhancements  were  in  the  finite  element,  dynamics,  and 
substructuring  sections.  These  changes  were  made  for  several  reasons,  l-irst, 
some  of  these  capabilities  were  designed  into  tlic  original  version  of  STRIJDI. 
but  were  not  fully  implementei.1 . Second,  some  - especially  the  substructuring  - 
needed  some  redesign  in  order  to  o])orate  in  a general  and  effective  fashion, 
rh i rd , changes  were  made  to  the  finite  element  sections  to  include  consistent 
loadings  for  most  element  t>])es  and  to  eliminate  elements  which  were  speci;il 
cases  of  more  general  elements. 

Uetails  on  all  enhancements  to  STRIJDE  are  documented  elsewhere. 


IV.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  development  of  CMS- ICES  and  VS- ICES  is  complete  and  both  versions  are 
being  used  for  production  runs.  The  various  changes  made  to  the  system  and  to 
STRUDL  have  resulted  in  substantial  performance  improvements,  assuming  judicious 
use  of  the  REORG  parameter. 

Additional  improvements  could  be  achieved  by  modifying  the  precompiler  to 
accept  Fortran  G statements  and  making  the  additional  changes  necessary  to  per- 
mit a variable  block  size.  These  additional  changes  were  not  done,  due  primar- 
ily to  time  limitations  on  implementation,  but  the  time  required  to  implement 
these  additional  changes  would  be  on  the  order  of  3 man-months. 

An  additional  improvement  which  could  be  made  is  to  develop  a facility  to 
access  DD4  from  both  CMS  and  VS. 
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Al'l’l.Nl'IX  A 


MAKINC,  nil-  aiS  ICES  MOUUU; 

The  CMS  ICtiS  Module  is  made  in  two  steps.  l irst,  LINKliOlT  ICEiS  is  executed 
which  [iroduces  an  ICliS  TEiXI’  file  consisting  of  the  programs  listed  in  tlie  ICEiS 
I IXKIilU  r file.  There  will  he  several  unresolved  externs  resulting  from  tliis. 

I ho  second  stej)  is  to  issue: 

ChOBAL  TX'ILIB  I-ORTI.IBN  lOUiT.lB 

I.OAIJ  ICnS  SYCONSl  QQCmtnK  MI.MORY70  ZQRIUL  ICI-SIO  SAVARlzA  QQFIOSH 
CHNMOD  ICES 


APPENDIX  B 


PROE.RAM  MODIPICATIONS  (CMS) 


A.  Changed  Programs 

1.  Function  1 i b r a.ry  programs 

a.  ALOCAT,  IRIT.ST,  ISTACK,  I.OADNM,  QQDELE,  QQDEST,  QQEINK,  QQLNIF, 
QQLOAD,  QQPLDl’,  QQPRIO,  QQSTAD,  QQSTDL,  QQSWCH,  QQSTEK,  OPTION, 
IDAREA 

Code  added  to  store  address  of  COMMON  in  register  4. 

b.  EXIT,  QQPOOl,,  QQDSNC,  QQINHT,  QQTRAN 

Code  added  since  COMMON  address  is  not  in  register  4 
on  entry. 

c.  I AVAIL 

Partition  size  determination  changed  to  constants. 

d.  QQDFIN,  QQINTI,  QQINT2,  QQINT3,  QQINT4,  QQINT5,  QQINT6 

Modification  due  to  COMMON  address  not  being  in 
register  4. 

e . QQS’IAT 

Correction  to  incorrect  handling  when  caller  has 
levels  specified  which  exceed  lowest  level  of  a 
dynamic  array. 

f.  SYIBCOM  - Csect  name  IBCOM 

Added  IllOF'DUMI’  and  DllMI’  as  entries  due  to  changes 
in  Fortran  C library  routines. 

Added  SiVMiSW  as  entry. 

Changetl  parts  of  program  since  register  1 does  not 
contain  address  of  COMMON. 
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Secondary  storage  programs 


a.  TABl.i:S 

Changed  to  use  CMS  disk  macros  (FCB)  rather  than 
OS  BI>AM  macros. 

b.  DlSKl 

Keference  to  INTSW  changed  to  INTSWTCtI  for  CMS  and  VS 
Fortran  G. 

Variable  branch  added  at  SFIF.  which  is  set  in  STRTICFS 
depending  on  whether  DF;BUG  option  is  given  or  not. 

Removed  all  WAIT  macro  code. 

Changed  WRITF  and  READ  to  FINIS,  STATE,  WRBUF/RDBUF. 

c.  DISKS 

Changed  tlie  MVC  for  the  ID  (or  TTR)  of  last  physical 
record . 

Added  code  to  force  writing  of  extended  logical  record. 

d.  DISK4 

Check  for  whether  DDNAMF.  was  specified  changed  to 
check  if  name  was  entered. 

Sections  to  move  in  DDN.AMF:  into  Dt.'B  modified  to  move 
name  into  FCB  and  set  up  FCB  parameters. 

lest  on  UISP  = NFW  altered. 

READ  section  changed  to  RDBUF'  section. 

Storing  of  blocks  initialized  altered. 

Section  added  at  F.Xri  to  make  sure  the  file  directory 
is  written  out  as  soon  as  possible. 

CI.OSE.s  clianged  to  FINIS. 


Added  section  to  force  IBCOM  to  return  to  DISK4  on 
exit  by  changing  SAVAR[;A(I2)  which  is  part  of  the  dum- 
my save  area  for  Fortran  G. 

WAIT  macros  removed. 

Branch  to  PDUMP  was  bypassed. 

ABDUMP  section  removed. 

Extend  data  set  section  changed  to  branch  to  error 
message . 

IN  IT  routine  removed. 

e.  DSKERR 

Modified  to  give  CMS  disk  error  numbers  from  RDBUF 
and  WRBUF. 

f.  DISKREPA,  DISKRITE 

Changed  to  put  common  address  into  QQCOMAPR  and  into 
register  4 for  use  by  interface  routines. 

5.  Command  interpreter  programs 

a.  COMl  - Csect  C0MINT$1 

VERU'Y,  M/\P,  and  *Ri;i'URN  were  added  as  immediate  com- 
mands. 'Hie  displacements  in  C0MINTfi2  DSECT  were 
updated. 

b.  COM2  - Csect  C0MIN'ni2 

Updatcii  the  displacements  in  C0MINT$1  DSl-CI. 

c.  CIERSl 

Calls  to  QQF.RSi;  and  QQERF'N  were  added  to  force  typing 
of  error  messages. 
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4 . Precompi I er 

ICPRECOM 

Section  added  to  type  error  messages  on  the  terminal. 

5 CDL  utility  programs 

DCCDIS,  CDLST 

Changed  to  put  address  of  COMMON  into  register  4. 

6 Initiation  programs 

a.  EXTERN 

Bound  changed. 

COMMON  section  added  to  force  a loader  table  entry 
for  common  when  the  ICES  module  is  loaded. 

b.  ICEX 

An  instruction  was  added  to  zero  register  15  upon 
normal  completion  of  an  ICES  run. 

c . INAL 

Section  added  to  store  COMMON  address  in  CMS  loader 
tables  and  in  QQCOMADR. 

d.  IN  IT 

lOKN'IRI,  extern  and  PC  added  for  inserting  its  ad- 
dress into  COMMON  and  the  MVC  for  this  clianged 
accordingly. 

SEGWT  removed. 

e.  SKFUDGE  - Csect  name  QQITIDGE 

Parameter  list  interpretation  was  rc’uovcd.  Partition 
and  machine  size  dote iiiii nat  i on  was  changed  to  use 
NUCON  tables. 
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a.  GTPOOL 

DUNIAR  made  DSECT. 

b.  qqio 


qqRERZ 


qqspc 


qqsTER 


REORPl 


Altered  to  get  COMMON  address  and  to  allow  Fortran  G 
to  use  register  13  as  base. 

Altered  to  permit  Fortran  G end  - parameter. 

DUMVAR  made  DSECT. 

DUMAR,\  made  DSECT 

Modified  to  set  mask  bit  in  lOKNTRL  in  MEMORY  to 
force  typing  of  message. 

DUMARE  made  DSECT. 


RGFAIL,  QERROR 

Reference  to  lOKNTRE  added  to  turn  typewriter  on  for 
error  messages. 

Call  to  MliMORY  to  give  map  of  primary  memory. 

SKFINCH2  - Csect  qqFINCll 

ilie  Dlil.F.TE  macro  was  fudged  t>y  changing  all  DlddiTF. 
macros  to  branches  to  an  added  section  of  code  called 
DELETE.  Hi i s section  issues  a FRLEMMN  for  the  space 
occupied  by  the  module  to  lie  Dl  (.1  IFiD.  It  also  re- 
moves the  name  from  the  CMS  loader  tables.  lli  i s was 
necessitated  by  the  |iroblems  with  the  LOAD  macro. 

The  Bl.DL  macro  was  clianged  to  a call  to  the  ZqRI  Dl. 
rout i ne . 
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Tlic  testing  for  and  size  computation  of  overlay 
modules  was  removed. 


The  l.OAl)  macro  was  replaced  by  two  sections  of  code, 
one  at  GOTCOR  and  one  at  LOAD  macro.  The  first  sec- 
tion issues  a GETMAIN  for  the  space  into  which  the 
module  will  be  placed  by  means  of  the  INCLUDE  command 
which  is  issued  in  the  section  at  the  LOAD  macro. 

i.  SYRTPRl,  DMRTSPC,  QQDCT,  QQSAVE 
SEGWT  macro  removed. 


8 ^ Miscellaneous  programs 

a . QQSNAP 

Changed  to  not  give  a dump. 


b.  QQSTUP 

Made  a dummy  since  not  needed  in  CMS. 


■New  Programs  for  CMS 
1 . Initiation  programs 

a.  ICEXl 

Replaces  ICEXl  and  TIMDAT  in  order  to  print  the  time 
and  date  without  using  a Fortran  program. 

b.  STRTICES 

This  program  initiates  the  ICES  module 

Checks  to  see  if  DEBUG  option  is  specified.  If  so, 
it  causes  a branch  around  the  issuance  of  the  SPIfi 
macro  in  program  DISKl. 

Calls  STRINI'I'  to  restore  any  lingering  free  space. 
Transfers  to  QQFUDGE. 


Program  and  memory  management  programs 


a.  MEMORY70  - Csect  name  MEMORY 

Routine  to  type  the  contents  of  memory  in  response 
to  a MAP  command  or  when  a memory  overflow  occurs 
or  when  in  DEBUG.  The  address  of  COMMON,  address 
and  lengths  of  POOLS,  address,  lengths,  and  names 
of  modules  are  typed. 

This  routine  contains  a displacement  in  routine 
SKFINCH  which  must  he  changed  if  a change  is  made  to 
FINCH . It  is  the  displacement  of  TABLE  in  FINCH . 

b . QQCOMAUR 

A csect  to  provide  storage  for  the  address  of  COMMON 
for  reference  by  the  root  and  other  routines. 

c.  SYEXSTUP  - Csect  name  EXSTUP 

Replaces  old  OS  EXSTUP  program.  Besides  doing  the 
standard  EXSTUP  functions  except  COMMON  address 
storing,  it  also  handles  the  DEBUG  mode  by  checking 
for  equivalence  to  debug  name  given,  calling  MEMORY 
for  a map,  reading  in  next  DEBUG  name,  and  issuing 
the  CMS  DEBUG  command. 

d.  ZQBLDL  - Csect  name  BI.DL 

Program  to  obtain  module  information  from  the  file 
STRUDL  BLDL  or  iubiij-ite.mname  BLDL.  It  replaces  the 
BLDL  macro.  The  module  information  is  stored  in  the 
caller's  BUST.  Call  is  with 

I.A  1,  BLIST 
L 15,  = A(BLDL) 

BAI.R  14.  15 
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BLIST.  Register  15  is  set  to  ;ero  if  no  errors  and 
to  1 otherwise.  Bl.lS'l  information  is  set  to  reusable, 
re-entrant,  nonscatter,  nonoverlay.  Aliases  are 
handled  properl). 

Rl.UI.  also  issues  a GLOBAL  TXTI.IB  command  for  all 
module  txtlibs  specified  in  the  BLDl.  file. 

riiis  routine  is  arranged  so  as  to  read  in  an  ICLS 
BLUL  containing  information  about  the  modules  used 
by  all  subsystems  (e.g..  Command  Interpretor)  and  a 
Bl.lU.  for  the  subsystem  ]iresently  being  used. 

BLDL  is  called  with  register  1 pointing  to  a 56  byte 
BUST  that  is  the  equivalent  of  the  BUST  used  by  the 
OS  BLDL  macro  with  the  module  or  alias  name  required 
l^eing  in  the  first  8 bstes.  BLDL  inserts  in  the 
BLISL  the  sice  of  the  module  and  if  the  BLIST  name 
was  an  alias  then  the  module  name  is  also  inserted. 

The  relative  entT\v  point  in  the  BLIST  is  set  as  :ero 
and  the  module  is  assumed  reusable,  re-entrant  and 
nonover 1 ay . 

BLUL  first  cliecks  to  see  if  any  Bl.DL  files  have  al- 
read>-  been  read  into  its  tal'le  and,  if  not,  then  the 
ILLS  BLDL  is  i-ead  in.  Then  if  there  is  a subs\'stcm 
name  in  the  first  8 b\tes  of  COMMON,  it  is  checked 
against  the  subsystem  name  of  any  BLDL  file  residing 
in  its  tables.  If  the  names  are  different  the  re- 
(piired  subsystem  BLDL  is  read  into  the  tal'les. 

If  during  the  read  of  an  ILLS  or  Subiiistci'nuxmc  BLDL 
file  the  name  TX'I'LIB  is  detected  starting  in  column  1 
of  an  entry,  tht'ii  tlie  I Xi  1 1 B name  given  is  inserted  in 
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tlie  parameter  list  for  a CMS  CLOBAL  TXTI.IB  command. 
Once  a TXTI.IB  has  been  detected  all  modules  following; 
this  entry  in  the  table  for  that  Bl.UL  file  are  marked 
as  being  in  ^ TXTI.IB  but  no  distinction  is  made  as  to 
which  TXTI.IB  they  are  in.  A CMS  Gl.OBAl.  TXTI.IB  command 
is  issued  for  all  the  TXTl.IBs  detected  after  a Bl.UL 
file  has  been  read  in.  Note  that  SYSl.lB  TXTLIB  is 
not  included  in  the  parameter  list  unless  specifically 
mentioned  in  a BI.DI.  file.  Note  also  that  i'Xil.lBs  will 
be  searched  in  the  order  entered  so  that  the  first 
copy  of  any  module  found  will  be  used  and  furtlier 
if  a ThXT  file  exists  for  the  module  it  will  he  used 
even  it  is  exists  in  a TXi'LlB.  The  CMS  dynamic  load- 
er searches  TXTl.IBs  onl>'  if  no  ThX'T  file  exi.sts. 

BLDl,  searches  its  tables  for  the  BI.IS'T  name  and  checks 
to  see  if  the  a[ipropriatc  module  exists  as  a liiXi 
file  unless  it  is  marked  as  being  in  a TXillB. 

BLDl.  checks  for  the  following  ei'rors  giving  the  mes- 
sage mentioned  and  setting  register  IS  to  1 to  indi- 
cate an  error  to  the  calling  program: 

"NO  name  BLDL  1-II.T;"  the  required  BLDl  file  does 
not  exist. 

"NO  nainc  i'X’TLlB  I'lLi;"  the  required  TXillB  does 
not  exist. 

"BLDL  RI;AD  LHROR"  disk  read  error  in  reading  a 
BLDL  file. 

"an  cntv{  THIS  LIST  lA'TRV  IN  1 RROR"  this  i ■.  m.t 
a correctl>  formed  BLDl  file  entr\.  Note- 
that  this  error  does  lu't  return  an  t'rror 
coile,  it  is  simplx  igiutred  in  the  ho]'e  th.it 
ttie  I'nt  r\  is  not  reqiiii-ed. 
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"BLDL  LIST  OVERl-LOK"  there  is  not  enough  room 
in  the  BLDL  table  (400  entries)  for  the 
BLDL  file  or  there  is  not  enough  room  in 
the  TXTLIB  list  (8  entries)  for  a TXTLIB 
name . 

"NO  LENGTH  IN  BLDL  LIST"  the  module  name  did  not 
hav'e  a length  included  in  its  entry. 

If  the  BLIST  name  cannot  be  found  in  the  BLDL  table 
or  if  the  module  name  could  not  be  found  if  the  BLIST 
name  was  an  alias  or  if  the  module  did  not  exist  as  a 
TEXT  file  and  the  entry  did  not  indicate  a TXTLIB, 
then  no  message  is  given  because  the  ICES  calling  rou- 
tine is  responsible  for  giving  the  appropriate  error 
message . 

A correct  BLDL  file  entry  for  a m.odule  name  contains 
the  name  left  justified  in  columns  1 to  8,  a blank 
in  column  9,  and  the  size  in  Z6  format  columns  10  to 
15.  The  size  must  start  with  a leading  zero  and  is 
the  size  in  hex  bytes. 

This  entry  is  stored  in  the  BLDL  table  with  a double 
word  for  the  module  name,  a full  word  for  the  size' 
translated  to  binary,  and  a final  word  containing 
zeroes  if  TXILIB  is  to  be  scarclied  and  'LIRE'  if  a 
TXTLIB  is  to  be  searched. 

An  alias  entry  in  the  BLDL  file  contains  the  name 
in  columns  1 to  8,  a blank  in  column  9,  and  the 
module  name  for  which  it  is  an  alias  in  columns  10 
to  1".  It  is  stored  in  the  BLDL  table  in  two  double 
words . 
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A TXTI.IB  entry  in  a Bl.DL  file  contains  the  name 
TXTIJB  left  justified  in  columns  1 to  6 and  the 
TXTLIB  name  left  justified  in  columns  10  to  17. 


5.  Input-output  programs 


a.  ICESIO  - Csect  name  IllCl  lOSIl 

Routine  to  go  between  IBCOM  and  (,'MS  to  direct  1/0 
on  datasets  5 and  6 as  desired.  Input  on  dataset  5 
can  be  from  typewriter,  CMS  file,  or  tape.  Output 
on  dataset  6 can  be  on  any  combination  of  typewriter, 
printer,  CMS  file  or  tape,  but  at  least  on  one.  Note 
that  disk  and  tape  arc  mutually  exclusive. 

INDIC  in  common  + .SOO  indicates  to  the  routine  whether 
a change  from  the  present  1/0  direction  is  required. 

If  the  last  5 bits  of  INDIC  are  zero,  the  present 
state  remains  in  force.  Otherwise,  they  specify 
what  state  is  required: 

INDIC  - Byte  J contains  the  indicators: 
bit  3 set  indicates  use  of  t;i]ie 

bit  4 set  indicates  out]iut  to  pi'inter 

bit  5 set  indicates  use  of  01S  file 

bit  b set  indicates  use  of  typewiiter 

hit  7 not  set  indicates  an  input  command 

bit  7 set  indicates  an  out]nit  command 

Thus  the  user  could  indicate  OUITIM  DISK  I’RIM  h\' 
setting  INDlti  to  13.  Noti'  that  hits  are  numbered 
0 to  7,  left  to  right  in  a liyte. 

FNAMh.  (8  bytes)  in  common  + 304  indicates  the  file- 
name to  he  usctl. 
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I'T'il’i;  (8  bytes)  in  common  + 312  indicates  tlie  filc- 
ty]'e  to  lie  used. 

IMODb  (4  bytes)  in  common  + 290  indicates  tlie  fileraode 
to  be  used  if  1/0  is  dislv  file  or  indicates  the  tape 
number  (1  for  I'APl)  to  be  used  if  1/0  is  tape.  Note 
that  ta[ie  and  disk  are  mutually  exclusive  on  output. 

tXitput  files  on  disk  are  added  to  if  tlie>'  exist. 

The  real  lllOI'lOSll  wliicli  tiiis  routine  intercepts  must 
be  obtained  from  tlie  ITirtran  ii  librari'  and  arranged 
witli  the  new  name  QQIMOSH  to  jirocess  tlie  calls  passed 
on  to  it  liy  this  routine. 

An  entry  I'YPH  is  included  in  ICISIO  that  can  be  used 
by  the  PORTKAN  call  CAI.I.  i'VPP;.  i'his  turns  on  the 
typewriter  no  matter  wliat  tlie  1/0  state  currently  is. 
There  is  an  additional  entry  lOk'NfRI.  which  indicates 
a double  word  containing  the  1/0  state  indicators, 
the  first  word  being  foi-  INPlI'f  and  the  second  for 
OUTPirr.  These  indicators  are  exactly  as  described 
for  the  COMMON  iiulicators  and  are  the  places  where 
ICP.SIO  saves  this  information.  Thus,  a iirogrammer 
may  intei’rogate  these  words  to  find  what  the  1/0 
state  is  or  to  change  tiu'  I/O  state.  A number  of 
ICIiS  roof  progi’ams  use  lOKNTRI,  to  turn  the  tipewriti'r 
on  before  giving  an  eri'or  message. 

b.  QQPRSC  - also  entrv  (^Ql  KI'N 

Subroutine  to  furn  on  t lu'  tipewriter  bit  for  output 
for  error  process  ing..  lUT  ermines  the  state  ot'  devices 
aiul  saves  them  so  that  Qt^l'HI  N can  restore  them  afti'r 
error  jirocessing  is  completed. 


38 


4. 


Miscellaneous  programs 


a. 


b. 


c. 


IHOASYNC 

A dummy  IHOASYNC  csect  to  prevent  unresolved  ex- 
terns  in  making  modules  for  TOPO  subsystem  and  STRUI'L 
subsystem. 

SAVAREA 

Dummy  section  for  Fortran  G savearea. 

STAESW 

Dummy  section  for  FORTRAN  librars'  reference. 


d.  STARTMOD 

This  program  replaces  program  SF"IT)F.  It  is  generated 
by  ])rogram  SETGF;N  or  SETCiF.Nl  , using  file  STARTMOD 
SAVE  as  a foundation  and  the  entries  in  the  BI.Dl,  file 
or  the  LIST  file  for  the  specific  module.  It  defines 
all  entries  to  the  module,  provides  information  for 
trace,  and  its  table  is  used  by  F.XSTIIF  to  sec  if 
DEBUG  should  be  entered. 


5.  Programs  for  module  generation 
a.  BLDLEDIT 

A new  routine  used  in  the  load  module  generation  pi'o- 
cedure  to  update  the  entry  in  the  BLl'i,  file  for  a 
module.  It  is  executed  with 


BLDLliDIT  iubicjitcmianm  QQmrdubaitamc 

and  searches  the  subsystemname  BI.DL  file  for  the 
entry  QQmcduTeiia/nc  commencing  in  column  1.  It  then 
searches  for  a QQmedtU'i’uamc  TF.XT  file  and  read'-,  its 
first  record.  It  checks  that  this  is  an  IS1>  ri'ci'rd 
containing  the  name  QQmet/uft’iutmc  and  moves  the 
three  byte  module  sice  to  columns  10  to  1 .S  of  tlie 
BI.DL  entry. 


b. 


LINKliDlT 


Tho  [.INKlilHT  moJulc  creates  dynamic  MODUl.l-.s  from 
'I'l-.Xr  files.  The  created  MOlUll.l.s  are  normal  relocat- 
able CMS  n;XT  files  witli  all  internal  references 
resolved  and  unreferenceable  b>’  other  routines.  The 
MOnUI.hs  are  entered  at  ladative  location  0,  with  tlie 
entry  name  bein^  the  MOlUll.li  name.  The  IT.XT  file 
created  has  the  MODIII.F  lenj^th  included  on  the  first 
liSli  card  so  that  it  ma>’  be  used  correct  1>  by  the  CMS 
dynamic  loading  routines.  I'lie  MOltUl.T  may  have  unre- 
solved e.xternal  references  to  other  routines  that  will 
lie  resolved  at  load  time.  I'lie  length  for  each  final 
COMMON  n.ame  is  the  largest  length  for  that  (XIMMON  name, 
but  this  length  is  ignored  b>  the  di’iiamic  loader. 


The  program  is  invoked  with  tlie  following  call: 


l.iNKi;i)l  1'  im-rfiinmc  ,■<  ( I'ciatmci  [cptifus]  txti  d'tuvfu’S 


where : 

mediutmc 

<\  ( t'cintmc  i 

en.s 


is  the  name  to  be  given  to  the 

1 INKld'lTed  file  created. 

are  the  luimes  of  the  IIXT  files  to 

be  includi'd  in  the  MObMlI'. 

are  IVl’f,  NO'I'VI'I  . I'KIN'l,  ami  NOI'ltlM. 

are  the  IXl'klBS  to  be  se.ircheil  for 

un  re.'.o  1 ved  reference-' . 


An  e.xi  sting  TIXT  file  with  the  name,  mi'i/tiitmc , will  In- 
erased  before  the  UNKIIUTmi  file  is  cre:itcd. 


II'  an  input  I'iU-  does  not  i-\ist,  a messay.t-  will  be 
tv[)cd  ami  proct'ssing  continued  ignorinj;  it.  It  is 
permissible  I'or  one  of  the  llAf  file-,  to  b(-  incliuled 
to  have  the  same  mime  a--  the  IIAT  module  to  be  c re.it  ed, 
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but  it  must  be  realized  that  it  will  be  replaced  by 
the  LlNKr.DlTed  module.  Note  that  because  the  TLXT 
module  is  entered  at  relative  location  0,  its  execu- 
tion will  begin  with  the  first  routine  to  be  included. 

Alternatively,  if  no  filenames  arc  specified,  the 
names  will  be  obtained  from  tlie  file  modnamc 
LlNKtDlT.  This  file  must  consist  of  80  character 
records  with  the  first  eight  ciiaracters  of  each  being 
a /)dlenarK.  Records  starting  with  a blank  in  column  1 
are  ignored,  and  a record  starting  with  an  * in  column 
1 terminates  the  obtaining  of  from  it. 

If  unresolved  external  references  exist  after  1.1  NKl-.lUT- 
ing  the  IT.XT  files  specifically  mentioned  in  the  para- 
meter list  or  the  l.INKF.lUi  file,  further  routines  are 
obtained  from  the  TX'lT.lBs  mentioned  in  the  parameter 
list.  Tlicse  TXTl.lBs  are  searched  in  the  order  entered. 
If  a blNKl-.Dll  file  is  being  used,  the  I'Xll.IBs  to  be 
searched  must  be  included  in  the  l.lNKlDir  file  as  for 
the  TliXT  files,  but  after  the  * record  mentioned  above. 

Although  any  combination  of  the  opticni  is  allowable, 
the  last  of  associated  will  be  used.  Ihe  de- 

fault options  arc  TVIT'  and  NOPRIN'l. 

The  possible  typed  and  printed  outinit  contains: 

a.  module  name 

b.  list  of  Ti:XT  files  included 

c.  external  references  left  after  TfXT  f i h's  used 

d.  TXTT.lBs  searched 

c.  size  of  the  MOnUl.li 
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The  I'YPl-  cipftcn  types  all  the  items  specified  above. 
The  PRINT  option  causes  all  the  items  mentioned  to  be 
output  on  the  off-line  jirinter.  NOPRINT  is  obvious. 
The  option  NOTYPH  inhibits  the  t>'jOn^  of  (h),  (c), 

(d) , and  (e) , but  error  messages  and  a list  of  the 
final  unresolved  external  references  in  the  MOUUTh 
will  be  typed. 

c . SliTGHN 

This  jirogram  creates  SrARTMOD  ASSliMBLl'.  from  STARTMOD 
SAVP.  using  the  modiU't’iiamc’  LIST  file  to  indicate  the 
entry  names  for  the  module.  The  entry  names  arc 
found  in  the  LIST  file  starting  in  column  10.  Tliey 
arc  included  in  STARTMOD  with  QQ  jircceding  tliem. 

d.  SLTCENl 

A similar  program  to  SliTOLX  but  iubsijitcmnami'  BI.UL 
is  searched  to  find  the  entr>’  names.  Tti  i s program 
is  called  with 

SLTOliNl  iubiips tomnamo  mociai'cnairK' 

The  iub5(/i fcmnamc  RLDI.  file  is  searched  for  medafe- 
namc  starting  in  column  .S.  Khen  found  it  is  checked 
for  consistency  in  tiiat  there  must  be  a QQ  in  columns 
1 and  2,  column  9 must  be  blank,  and  column  10  must 
contain  a zero.  Only  such  luitries  are  accepted  as 
correct  module  entries.  The  module  name  and  follow- 
ing alias  names  .iri'  placed  i ti  the  STARTMOD  ASSI.MHI.r 
file  being  created.  Mias  names  must  he  in  ('tifries 
immediate!)'  following  the  moduli'  name  ent  r\-  and  must 
contaitt  QQ  in  columtis  1 and  J,  a blank  in  column  0, 
;ind  (IQmcdnf I'Hitmi’  in  ci'lumns  1(>  to  I”.  \n>thing  else 
is  tre.'iteil  as  an  error. 


C . Summary  of  New  and  Changed  Programs 


CHANGED 

NEW 

AI.OCAT 

IN  IT 

QQLNIF 

BLDLEDIT 

flil.ST 

I R LE ST 

QQLOAD 

ICESIO 

ClHRSl 

I STACK 

OQPLDP 

ICE  XI 

fOMl 

LOADNM 

QQPOOL 

IHOASYNC 

COM2 

OPTION 

QQPRIO 

LINKED IT 

DCCDIS 

PRECOM 

QQRERZ 

MEMORY70 

DISKREPA 

QERROR 

QQSAVE 

QQCOMADR 

DISKRITE 

QQDCT 

QQSNAP 

QQERSG 

DISKl 

QQDELE 

QQSPC 

SAVAREA 

DISKS 

QQDEST 

QQSTAD 

SETGEN 

UISK4 

QQDFIN 

QQSTAT 

SETGENI 

DSKERR 

QQDSNC 

QQSTUL 

STAESK 

EXIT 

QQINHT 

QQSTER 

STARTMOU 

EXTERN 

QQINTI 

QQSTLK 

STRTICIIS 

FINCH2 

QQINT2 

QQSTUP 

SYI.XSrUP 

FUDGE 

QQINT3 

QQSWCll 

ZQBLDL 

GTPOOL 

QQINT4 

QQTRAN 

I A VAIL 

QQINT5 

REORPl 

IBCOM 

QQINT6 

RGFAI L 

ICEX 

QQIO 

RTPRl 

IDAREA 

QQLINK 

RTS  PC 

INAL 

TABLIiS 
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APFl-.NDIX  C 

PROGRAM  MOD  H' I CAT  IONS  (l^S ) 

A.  Changed  Programs 

1 ■ Secondary  storage  programs 

a.  OSTABLLS 

Macros  changed  to  BUAM. 

Constants  changed  for  block  size  of  4000. 

b.  OSDSKBPS,  OSSAB 

Changed  for  block  size  of  4000. 

c.  OSDISKl 

Restored  all  WAIT  macro  code. 

Changed  CMS  macros  back  to  BD/\M  macros 
Changed  constant  for  4000  block  .size. 

d.  DISK2,  niSK6,  DISK7 

Reassembled  with  VS  version  of  DISKUATA  macro 
generation. 

e.  OSDISK.S 

Removed  clianges  made  to  original  OS  version  for  CiMS 
version . 

f.  0SDISK4 

CMS  changes  were  restored  to  original  form  exce])t 
for  section  added  to  force  IlUiltM  to  return  to  DlSkl 
which  was  left  the  same  as  the  CMS  addition. 

Constants  changed  for  block  size  of  4(U)0. 

g.  0SD1SK5 

Instruction  changed  for  block  size  of  ll'OO. 
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2.  Precompiler 

OSPRECOM 

Removed  section  to  type  error  messages  on  the  terminal. 

3.  Initiation  programs 

a.  OSEXTERN 


COM  section  removed. 


b.  OS FUDGE 

Restored  CMS  removals. 

c.  OSICEXl 

Restored  to  original  form. 

d.  OS  INAL 

References  to  CMS  loader  table  removed. 

e.  OSTIMDAT 

Changed  so  does  not  type  but  returns  information  to 
be  printed. 

4.  Program  and  memory  management  programs 

a.  0SFINCH2 

Changes  for  DELETE  macro  were  restored  to  original. 

BLDL  macro  was  restored. 

Overlay  computation  was  restored. 

LOAD  macro  changes  were  restored  to  original. 

Note  again  that  any  change  to  0SE1NCU2  must  be  reflec- 
ted in  a change  to  the  table  displacement  ciinstant  in 
OSMEM70  at  TAB!) ISP. 

b.  OSGTPOOl, 

Changed  so  that  contiguous  pools  will  not  he  made  into 
one  pool . 


l.S 


c.  OSMLM70  - Csect  name  NlliMORY 

I Out]H(t  operations  changed  to  OS  BSAM  macros.  Output 

' is  printed  on  DDname  i'l'Ofal'OOS. 

5.  Input-output  programs 

j OSlChSIO  - Csect  name  IllCl'lOSll 

I I/O  Operations  changed  to  OS  BSAM  macros. 

I Hie  typewriter  mode  for  outjnit  is  meaningless  in  VS. 

I Standard  input  is  from  DDhcVHC  I'i'OSFOOl  (corresponds 

to  CMS  TYl’li  input). 

Alternate  default  input  is  from  DUnamc  ICfSIM’i 
(corresponds  to  CMS  I'li.i  input). 

Standard  output  is  on  liDnamc  li'OblOOl  (corresponds  to 
■ CMS  PRINTliR  output).  Alternate  default  output  is  on 

DDiianui  ICliSOlli  (corresponds  to  CMS  I'll.li  out(iut). 

Input  and  output  to  lAI'I;  is  meaningless  in  VS  since 
the  DD  card  defines  the  medium  and  the  macros  are  in- 
dependent  of  device  (disk  or  tape)  for  sequential 
files.  Switcliing  can  still  (le  done  (as  in  CMS)  Init 
^ between  DDudmi’i  l-i'OSl  ODl  and  IChSl.NPT  or  >)<  fcmtini' , 

or  between  I 'lOul  OOl  and  ICHSOUi  or  Ccnamc . Note 
that  here  is  tlie  name  given  in  tlie  IN  or 

OUT  command. 

-■  _ Module  generation  programs  ( 

FUBAR2 


Removed  ovei'av  c)ieek. 


Miscellaneous  programs 


a.  OSQQSNAP 

Restored  to  its  original  OS  form. 

b.  QQQQINIT 

VS  only.  Changed  from  OS  version  to  permit  block 
sice  of  -tOOO. 

B.  New  Programs  for  VS 

1.  .Module  generation  programs 

a.  ADTAB 

Called  by  program  OSSETGEN  to  find  all  adcons  to 
COMMON  in  a specified  object  program  and  return  these 
adcons  to  program  OSSF.TGEN.  The  object  program  must 
be  a member  of  a partitioned  dataset  defined  on  a DD 
card  with  DDname  OB.J. 

b.  MXCO 

This  program  changes  the  length  of  COMMON  in  a TEXT 
file  to  4.  I'he  name  of  the  file  is  read  from  dataset 
number  5.  This  program  is  invoked  in  the  PRECOMP 
procedure  after  compilation.  It  calls  program  NIXCOl. 

c.  NIXCOl 

Used  with  NIXCO  in  changing  the  length  of  the  ESI) 
card  for  COMMON  in  a TliXT  file  to  a length  of  4. 

d.  OSSETGEN 

Creates  the  SETUP  program  for  VS  load  modules.  SE'lUl’ 
is  the  entry  point  and  starting  program  for  all  \'S 
load  modules  in  an  UiES  subsystem.  It  also  generates 
the  necessary  input  cards  for  the  linkage  editor  for 
generating  a load  module  for  ;i  subsystem.  It  calls 
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program  A[)TAB  to  find  all  uJcons  to  COMMON  in  each 
subprogram  to  be  included  in  a load  module.  Appro- 
priate code  is  then  generated,  to  be  a part  of  the 
generated  Sl-TUI’  program,  to  resolve  all  such  adcons 
to  the  correct  subsystem  COMMON  address  each  time 
the  module  is  loaiied  during  a subsystem  execution. 

e . SETUF’ 

Replaces  the  t.'MS  STAKTMOU  program.  It  performs  all 
the  functions  that  the  STARTMOI)  program  performed. 

It  also  takes  care  of  the  common  resolution  function. 
iTiis  is  performed  by  code  and  table  generated  by  pro- 
grams OSSbTGliN  and  ADiAB.  lit  is  code  goes  through  the 
table,  which  consists  of  addresses  of  adcons  for 
COMMON,  gets  the  relocated  value  for  that  adcon,  sub- 
tracts the  relocation  constant  (the  address  of  link- 
edited  COHMON")  from  the  value,  adds  the  actual  address 
of  CiOMMON  to  tlie  value,  and  stores  tlte  new  value  back 
in  the  location  of  the  adcon. 

Miscc  1 1 aneouj^  ro^rams 

c:ross 

Produces  a cross  reference  listing  of  pi'ograms  in  an 
U!i;S  subsystem.  Input  to  this  program,  which  runs  on 
CMS,  comes  t‘i-om  dataset  number  8 and  is  the  set  of 
VS  Sl.TGP.N  ininit  records  for  that  subsystem.  Output 
is  directed  to  dataset  number  10. 


IS 


i 


c:  Summary  of  New  and  Changed  Programs 


CHANGED 

NEW 

DISKI 

ADTAB 

DISK2 

CROSS 

DISKS 

NIXCO 

DISK4 

NIXCOl 

DISKS 

OSSETGEN 

DISK6 

SETUP 

DISK? 

DSKBFS 

EXTERN 

FINCH2 

FUBAR2 

FUDGE 

GTPOOL 

ICESIO 

ICEXl 

INAL 

MEMORY70 

PRECOM 

QQQQINIT 

QQSNAP 

SAB 

TABLES 

TIMDAT 

•I 

J 
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APl’liNUIX  D 


SUMMARY  01'  lets  RfiLAThU  CMS  FILHS 


EXEC  files 

+ PRECOMR 
+ MAKEMOD 
->•  EXECICE 

MODULE  files 

ICETRAN 

SETGEN 

SETGENl 

LINKEDIT 

BLULEDIT 

ICES 

GROSS 

RLm,  nj_es 

ICES 

QQCDLCDP 

STRUDl, 

TOPO 


NlMUU_B_EiJcs 

ICESLIB 
OS  ice:  I,  IB 


'IXTLIB  files 

CDLMOUS 
ICESMODS 
ICE.  LIB 


ia;s  n ii^ 

DUS 

dd: 

DDMASTR 

Otlier  Pile 

+ STAR'l'MOD  SA\'i; 

BSOS.IOB  OSJOBl.lJI  _fi_Ic 

+ BSSIROBJ 
+ BSSTRSE.T 
+ BSPRLCOM 
+ BSSTRUDl, 

+ BSSTURELS 


^ Listing  of  these  files  can  t>e  fouiul  in  Appeiul  i x I. 
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APPENDIX  E 


LISTINGS  OF  SOME  FILES  AND  PROCEDURES 


STARTMOD 

SAVE 

PRECOMP 

EXEC 

MAKEMOD 

EXEC 

execice 

EXEC 

BSSTROBJ 

OSJOB 

bsstrset 

OSJOB 

BSPRECOM 

OSJOB 

BSSTRUDL 

OSJOB 

BSSTURES 

OSJOB 

SI 


' 
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FILE:  STARTHOD  SAVE 


STARTMOD 


QOLODADE 

QQSETUP 


INTSM 

OOSA VEAR 

OQTRACE 

OOCOMADR 

QOTBADR 

OQPHOGNM 

QOFINCHL 

QQLODPT 

OOSTPAD 

INTSWLOC 

OOCOUNTS 

OOTA  BLE 


CSECT 

ENTRY 

QQCONADR 

STA00010 
STAOOO  20 
STAOOO  30 

ENTRY 

QQSETDP, QQFINCHL.QQSAVEAR .QQTABLE , IHTSH .QQLOD ADR 

STA00040 

EQO 

* 

STA00050 

STB 

14,12,  12(13) 

STA00060 

BALR 

12,0 

STA00070 

USING 

•,12 

STA0003C 

LA 

S.OOSAVEAR 

ST  AO  00  90 

ST 

1 3,4  (C,5) 

STA00100 

ST 

5,0(0,  13) 

STA001 10 

LR 

13,5 

STA00120 

L 

2,0(0,  1) 

STA001  30 

BVC 

OOPBOGNB  (8)  ,0  (2) 

STA00140 

L 

4,4(0,  1) 

ST  AO  0 1 50 

ST 

4,0QCOBADR 

STA00160 

LA 

15, INTSM 

STA00170 

ST 

15,INTSMLOC  (4) 

STAOO10C 

L 

1 = ,QQSTPAD(4) 

STA00190 

BALR 

14,15 

STA00200 

DC 

AL1  (0) 

STA00  210 

DS 

18F 

STA00220 

DS 

4F 

STA00230 

DS 

IF 

STA00240 

DC 

A (QQCOUNTS) 

STA00250 

DS 

JP 

STA00260 

DC 

A (00 PROG  NB) 

STA00270 

DC 

A (QQLODADR) 

STA00280 

FOU 

264 

STA00290 

EQU 

284 

STA00300 

DC 

AL4(TABLEND) 

STA0031C 

EQU 

* 

STA00330 

FILE:  PRECOMP  EXEC 


6CONTROL  OFF  NOHSG 

STATE  61  ICETRAN 

6IF  6RETCODE  NE  0 SGOTO  -NOFILF 

ERASE  61  FORTRAN 

ERASE  ICETRAN  SCRATCH 

6ERROR  6GCTO  -CLEAN 

FILEDEF  FILE1  DISK  61  ICETRAN  A1  (RECPH  FS  BLOCK  80) 

FILEDEF  FILE2  DUMMY  (RECFM  FS  BLOCK  80) 

FILEDEF  FILE3  PRINTER 

FILEDEF  FILE4  DISK  61  FORTRAN  A1  (RECFM  FS  BLOCK  80) 

FILEDEF  FILES  DISK  ICETRAN  SCRATCH  A1  (RECFM  FS  BLOCK  1600) 

CP  SPOOL  PRINTER  CONT 

LOADMOD  ICETRAN 

START  ICETRAN 

FORTGI  61  (PRINT) 

! ERASE  61  FORTRAN 

CP  SPOOL  PRINTER  NOHOLD  NOCONT 

ERASE  ICETRAN  SCRATCH 

CP  CLOSE  PRINTER 

6X  = 61 

6STACK  CX 

NIXCO 

I 6FXIT  0 

-CLEAN  6C0NTINUE 
; 6ERRCR  6CONTINUE 

■ ERASE  61  FORTRAN 

f-  CP  SPOOL  PRINTER  NOHOLD  NOCONT 

;i  ERASE  ICETRAN  SCRATCH 

« CP  CLOSE  PRINTER 

6EXIT  10 

j -NOFILE  6EXIT  99 

! ERASE  61  FORTRAN 


i; 


FILE:  KAKEMOD  EXEC 


&EHROR  &CONTINOE 
6CONTROL  ERROR 
6INDEX1  = 1 

6IF  6INDSX  GT  1 6GOTO  -BLDL 
6APGS  61  61 
6TYPE  SETGEfi 
SETGEN  61 

6IF  6RETCCDE  NE  0 6GOTO  -END 

6GOTC  -ASS 

-BLDL  6SYS  = 61 

6INDEX1  = 2 

6TYPE  SETGEN1 

SETGEN1  61  62 

6IF  6RETCODE  NE  0 6G0T0  -END 

6CONTPCL  OFF  NOMSG 

STATE  62  LIST  * 

eiF  6RETCODE  NE  0 6GOTO  -LIST 

6ARGS  62  62 

6GOTO  -ASS 

-LIST  STATE  61  LIST  • 

6IF  6PETCODE  FQ  0 6G0T0  -ASS 
6TYPE  NO  61  LIST  FILE 
6GOTO  -FND 
-ASS  6C0NTIN0E 
6C0NTR0L  FRFOR 
6TYPF  ASSEMBLE 

GLOBAL  MACLIB  ICESLIB  SYSLIB 
ASSEMBLE  STARTMOD  (NOLIST) 

6IF  6RFTCODE  NE  C 6G0T0  -END 
COPY  61  LIST  • 0062  LINKEDIT  A1 
6TYPE  LINKEDIT 
LINKEDIT  0062  (MAP  PRINT) 

6IF  6RETCODE  NE  0 6INDEX1  = 1 

ERASE  0062  LINKEDIT 

6IF  6INDEX1  LT  2 6GOTO  -END 

6TYPE  BLDLEDIT 

BLDLEDIT  6SYS  0062 

-END  6CONTINUE 

6C0NTR0L  OFF  NOMSG 

ERASE  STARTMOD  ASSEMBLE 

ERASE  STARTMOD  TEXT 

CLOSE  PRINTER 

PRINT  LINKEDIT  MAP 

6EXIT 


FILE:  EXECICE  EXEC 


£FN  = ZIP 

fcIF  EINDEX  NE  2 6G0T0  -STOB 
6FN  = SI 
SFT  = 62 

-STOR  STYPE  IS  STORAGE  DEFINED  AS  1024K  ?? 

SPEAD  ARGS 

6IF  SI  NE  YES  SGOTO  -DSTOR 

6IF  SEN  NE  ZIP  SGOTO  -TDSK 

-NME  STYPE  ENTER  INPUT  FILENABE  FILETYPE 

SREAD  ARGS 

SIF  SINPBX  NE  2 SGOTO  -N«E 

6FN  = 61 

SFT  = S2 

-TDSK  EXEC  TDISK 

SCONTPOL  ERROR 

''RASE  DDU  ICES  D1 

FFASE  SEN  OUTPUT  D1 

ERASE  ICES  OUTPUT 

UN  SHA«  E 

SFFRCP  SEX  IT 

SPARE  BLIVET  B2 

SHAPE  FANNING  C2 

COPY  DDBASTP  ICES  C2  DDU  ICES  D1 
UNSHAPE  FANNING 
6A  = * 

SX  = SCONCAT  6A  6FN  6 A 
6Y  = SCONCAT  SA  SFT  6A 
S'TACK  ICES 

6STACK  OUT  DISK  SX  'OUTPUT*  'D1' 

S-STACK  IN  DISK  SX  6Y 

6 STACK  FIN 

SEND 

6FXIT 

-DSTOR  STYPE  DEFINE  STORAGE  AS  1024K  , RE-IPL,  AND  RE-START 
S E X I T 


FILE;  BSSTROBJ  OSJOB 


//  ' SCHUMACKER  0201  73 ■ ,TIBE=3, CLASS=B, CPU=L 
//  EXEC  PGB=IEBOPDTE 
//SYSPRINT  DD  SYSOUT=A 

//SYSUT2  DD  DSN=ICES.OBJ.NEHSTBDD,DISP=OLD,ONIT=PDISK, 
//  VOL=SER=D67,  DCB=  ( RECFB  = PB,  LR  ECL  = 80  , BLKSI  ZE  =800)  , 

//  SPACE=(CYL,  (35,2,200)) 

//SYS0T1  DD  DSN=ICES.OBJ.HEHSTRUD,DISP=OLD,ONIT=PDISK, 
//  VOL=SER=D67,DCB= (RECFB=FB,LRECL=80 ,BLKSIZE=800) 
//SYSIN  DD  * 
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FILE:  BSSTRSET  OSJOB 


//  • ''.CHUK  ACKER  0 2C  1 7 3 ' ,T  I«  E = 3 , CL  A SS=B  , CP  U=  L 

//SETUP  EXEC  PGM^OOFUB AR2 

//STFPLIP  DD  DSN=ICES.NEWLINK.DISP=SHH,UNIT=PD1SK,V0L=SEE=D67 
//Sy^PRLNT  DF  SVSOUT=A 
//SYSUDUC.F  D[)  SYSOUT  = A 

//FT06F001  DO  SY  SOUT  = A , DCB=  (R  ECF«  = UA  , BL  K SI  ZE  = 1 33  ) 

//FT07FO0"!  DD  SYSOUT  = B 

/'FT02FCC"’  DD  UN  TT  = T DISK  , SP  AC  E=  ( TRK  , ( 1 0 , 1 0)  ) , DI  SP=  (NEW  , PASS)  , 
//  DCP=  (FECFM=F,BLKSIZE  = 60) 

//SY:  PUNCH  DD  UNIT  = PDISK,DISP=  (NEW, PASS)  , SPACE*  <80,  (25,25)  ) , 

//  DCB=  (FECFN^F,  BLKSIZE=80)  , VOL=SEP=D67 

//FTCUE001  DD  UNIT  = PPISK,SPACE=  (80  , (25,25)  ),  DISP=  (NEW,  PASS)  , 

//  PCP=  (FECFM*F,  BLKSIZE*eO)  ,VOL=SEE=D67 

//SYSUT2  DD  UNIT  = TDISK,SEACE=  (CYL,  (1,1)  ) ,DCB  = BLKSIZE=3520 
//SYSUTI  FD  UNIT*TDISK,SPACE=(CYL, (1,1) ) ,DCB=BLKSIZF=3520 
//-ACL  It-  PD  DSN*  ICES.  NE  WKAC , DI  SP  = S H R ,UN  IT*  PD  IS  K , VOL  = S ER*  D67 
//SYSLIB  DD  DSN=ICES. NEWFUNC, DISP*SHR, UNIT=PDISK , VOL=SER=D67 
//  DD  DSN=SYS1.FCETLIB,CISP=SHR 

//SYSIMOP  DD  DSN=ICES.MOLULES.NEWSTRUD,UNIT=PDISK,DISP=CLD, 

//  VOL=SER=D67 

//OBT  DD  rSN*ICES.CBJ.NEWSTRUD,DISP*OLD,UNIT=PDISK,VOL=SER*D67 
//SYSUT1  DD  UNIT  = TDISK, SPACE*  (CYL,  (1  ,1)  ) ,DCB  = BLKSIZE=3520 
//SYSLIN  DD  DSN=*.  SYSPUNCH,  DCB*  (RECFf!  = F,  BLKSIZB*80)  , 

//  VOLtl«E  = REF=*.  SYSPU  NCH , DI  SP=  ( OL  D,  PASS) 

//  DD  DSN*»-,FT04F0C1  , 

//  VOLUf1F=REF=*.  FTC4F001,  DISP=( OLD,  PASS) 

//FTO'^FOCI  DD  UNIT=TDISK,SPACE=(80,  (50,50)  ) 

//SYSIN  CL  * 


FILE:  BSPPECOH  OSJCB 


//ICETEiN  EXEC  PG H= QQFU PXF , F A EH  = ST 

//STEPLIB  DD  DSN=1CES. NE«LINK,DISP=SHB,ONIT=PDISK,?OL=SEE=E67 
//F1LE2  DP  DUHHY 
//FILE3  DD  SYSOOT=A 

//FILB«  DD  DNIT  = TDISK,SPACE=  (CYL,  ( 1,  1(  ) »DCB=BLKSIZE  = 3520 
//FILES  DD  U(IIT=TDI  SK,SPACE=  (CYL,  (1  ,1)  ) , DCB=BLKSIZE=3520 
//SYSTERB  DD  SYSOUT=A 
//SYSUDUHP  DD  SYSOUI=A 
//SYSPRINT  DD  SYSOUT=A 

//SYSUT1  DD  UNIT  = TDISK,SPACE= (TEK,  (10,10))  ,DCB=BIKSIZE  = 3520 
//SYSUT2  DD  UNIT=TDISK,SPACE=  (TEK,  ( 10,  10)  ) ,DCB=BLKSIZE=3520 
//OUTPUT  DD  DISP=  (BOD  , PASS)  , DCB=  (EECFB=FB,  LR  ECL=  80  , BLKSIZE=800)  , 

//  0»IIT  = TDISK,SPACE=  (TEK,  (10,10,20)) 

//SYSLIN  DD  ONIT=TDISK,SPACE= (TRK, (1C, 10)) , DCB= ( RECFB=FB ,LRECL-80 , 
//  PLKSIZE  = H00)  ,DISP=  (,PASS) 

//PILE1  DD  *,DCB=BLKSIZE=eC 

/^ 
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fTLE:  BSSTSUDL  OSJOB 


//  • SCHllBACKER  OJOl  7 3 • ,TI  HE  = 3 ,CL  ASS=  D,  CPU=  L 

t //ICETST  EKEC  PGH =QQQICEX5 , P ARM = 1 500 

//STEPLIB  PP  DSStKE=lCES.  HEVLI  SK . DISPOSES,  OSIT •‘PDISK,  VOL=SEE  = D61 
//  DD  rSN^ICES.  MODULES.  NEKSTHUD,  DISP  = SHR,  miIT  = PDISK,VOL=SEE=D67 
//PTP6E001  DD  SYSOUT  = A ,DCB=  (RECFH=UA,BLKSIZE  = 1 33) 

//XCrSOUT  DD  SXSOUT^A,  DCB=  (KECFM=UA,BLKSIZE=133) 

//FT06FC02  DD  SYSOUT=A 
//rT0fFCO3  DD  SYSOUT=A 
//FT07F001  DO  SYSOUT=B 

//DD1  DD  UNir  = TDISK,SPACE=  (1*000,  (10,  1)  ) ,DCB=  (D  SOHG=DA  , BL  KSI  ZE=4  000)  , 
//  DSNAME=&STUDL1 

//DD2  DD  DSN=ICES. DATA. NEHSTHUD, D1SP=0LD,0NIT=PDISK, 

//  vn  = SIR  = D67,DCB=  (DSOFG  = D A , BLKSIZE=400C  ) 

//DD'i  DD  DSN  = ICES.CDBS.NEW,DISP=OLD,UNIT=PDISK, 

//  YOL  = SFR  = D6  7,DCB=  (DSOEG=DA  ,BLKSIZE=4  000) 

//DD4  DP  UNIT  = TDISK,SPACF=  (4000,  (1200,  100)  ) , 

//  DCB=  (DSORG  = DA  ,BLKSIZE  = 4000)  , 

//  DSNAME=6STUDL3 

//SY  UDUMF  DD  SYSOUT=A 
//F7C5FC01  DD  DDNAME  = SYSIN 
//SYSIN  ID  * 


FILE:  BSSTUPES  OSJOB 


//  'SCHUMFCKEP  0201  7 3 • , TIME=3 , CL A SS=B , CPU=L 
//ICETST  EXEC  PGN=QQQICEX 5 , P APH = 1 500 

//STEP  LIB  DD  DSNAME  = ICES. NEMLINK,DISP  = SHR,UN1T  = PDISK,V0L  = SER=D67 
//FT06F001  DD  SY  SOUT=  A , DC  B=  ( R ECFH  = UA  , BLK  SI  ZE  = 1 33 ) 

//FTOFF002  DD  SYSOUT=A 
//FT07F001  DD  SYSOUT=B 

//DD1  DO  UNIT  = TDISK,SPACE=  (UOOO,  (10,1)  ) ,DCB=  (DSORG=DA,  BL  KS  IZ  E=U000)  , 
//  DSNANE=GSTUDL 1 

//DD2  DO  UNIT  = TDISK,SPACE=  (4000,  (10,1)  ) ,DCB=  (DSORG=DA,  BL  KS  IZ  F=4  000  ) , 
//  DSNA.')F-&STUDL2 

//DM  DD  DSN =ICES.CDBS. NEH,DISP=OLD,UNIT=PDISK, 

//  VOL  = SER=  D6  7,  DCB=  ( DSOFG  = DA  , BL  KS  IZ  E = 4 000) 

//004  DD  UNIT  = TDISK,SPACE=  (4000,  (10,1)  ) , 

//  DCB=  (DSORG=DA,  BLKSIZF  = 4('00)  , 

//  DSNAME*6STUDL3 

//SYSIIDUMF  DD  SYSOUT=A 
//FTO'^FOOI  DD  DDNAME  = SYSIN 
//SYSTN  DP  » 

CDL 

SYST''N  'STRUDL  • 'RDL* 

COPINON 
•INPIC  3CC 
END  COBflON 


F'^START  'STRUDL  ' 'RDL' 
SIZE  OF  COMMON  3500 
SIZE  OF  POOL  81920 
MODULE  LINK 
FPESET  ALPHA  8 'OQDUB' 

EQUAL  'STRUDL  ' 

PPESFT  INTFGEF 

' INDIC 

EO  9 

fFSSAGE  * ' 
fIFSSAGE  * 

A*** 

MESSAGE  ' 

* 

“ESSAGE  ' 

♦ 

ICES  STRUDL-III 

f-FSSAGF  * 

THE  STRUCTURAL  DESIGN  LANGUAGE 

*1FSSAGE  ' 

Ik 

rESFAGE  * 

* 

LINCOLN  LABORATORY 

I*EGSAGE  * 

MASSACHUSETTS  INSTITUTE  OF  TECHNOLOGY 

MESSAGE  ' 

CAMBRIDGE,  MASSACHUSETTS 

MESSAGE  ' 

* 

V3  MO  FEBRUARY,  1976 

EXECUTE  'STIME' 
•'■SSAGE  ' 

MESSAGE  ' 

J LOOK  FOP  STRUDL  RESTORE  'ID' 

DATA  CHECK  SET  'IK' 

CONDITION  'IK'  EQ  0 
CALL  'MESSAGE' 

NEW  COMMAND 
OTHERWISE 

NO  TO  ALPHA  fl  'JOBID'  STANDARD  'NONE* 

NO  ID  ALPHA  64  'TS'  STANDARD  'HONE  GIVEN' 
ID  'POOL'  INTEGER  'll'  STANDARD  0 
ID  'MESS'  ALPHA  4 '12'  STANDAPP  'ON  • 
CONDI-"ION  ALPHA  4 '12'  EO  'ON  • 

CALL  'MESSAGE' 

END  CONDITION  OPTIONAL 
PRESET  '10'  EO  6 
EXECUTE  'STINMD' 

END  CONDITION 
FILE 
FINISH 
/• 
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